NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/722

Internet Message Format | 1996-08-06 | 1.7 KB

Path: stdc.demon.co.uk!clive
From: [e-mail] (Clive D.W. Feather)
Newsgroups: comp.std.c
Subject: Re: Restrictions on qsort compare function?
Date: Wed, 10 Apr 1996 23:24:26 GMT
Organization: Demon Internet Limited (personal account)
Message-ID: <[e-mail]>
References: <4kbl1l$[e-mail]> <[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: stdc.demon.co.uk

In article <[e-mail]>,
Lawrence Kirby  <[e-mail]> wrote:
>"Undefined behaviour is otherwise indicated in this International Standard
> by the words ``undefined behaviour'' or by the omission of any explicit
> defintion of behaviour. There is no difference in emphasis among these
> three; they all describe ``behaviour that is undefined.''"
>
>This means that code has undefined behaviour unless you can show what the
>defined behaviour is according to the standard. In all of your examples
>the behaviour can vary depending on the actual implementation of qsort().
>In the absense of any other limitation in the standard (such as a statement
>of implementation-defined behaviour), this means the behaviour is undefined.

No, this is circular logic. A library function must be inferred to do
only what its specification says, and nothing else; you can't use
undescribed behaviour to deduce that a specific call to that function is
undefined. Otherwise you could say "and abs() might set all long variables
to 0".

--
Clive D.W. Feather                       | If you lie to the compiler,
[e-mail]   (work, preferred) | it will get its revenge.
[e-mail] (home)            |   - Henry Spencer